When ppppccccnnnnffffssssdddd receives a PPPPCCCCNNNNFFFFSSSSDDDD____AAAAUUUUTTTTHHHH or PPPPCCCCNNNNFFFFSSSSDDDD2222____AAAAUUUUTTTTHHHH request, it will "log
in" the user by validating the username and password and returning the
corresponding uid, gids, home directory, and umask. If ppppccccnnnnffffssssdddd was built
with the WWWWTTTTMMMMPPPP compile-time option, it will also append a record to the
wwwwttttmmmmpppp(5) data base. If you do not wish to record PC "logins" in this way,
you should add a line of the form
wwwwttttmmmmpppp ooooffffffff
to the ////eeeettttcccc////ppppccccnnnnffffssssdddd....ccccoooonnnnffff file.
By default, ppppccccnnnnffffssssdddd will only allow authentication or print requests for
users with uids in the range 101 to 60002. (This corresponds in SVR4 to
the range for non-system accounts.) To override this, you may add a line
ppppccccnnnnffffssssdddd supports a printing model based on the use of NFS to transfer the
actual print data from the client to the server. The client system issues
a PPPPCCCCNNNNFFFFSSSSDDDD____PPPPRRRR____IIIINNNNIIIITTTT or PPPPCCCCNNNNFFFFSSSSDDDD2222____PPPPRRRR____IIIINNNNIIIITTTT request, and the server returns the
path to a spool directory which the client may use and which is exported
by NFS. ppppccccnnnnffffssssdddd creates a subdirectory for each of its clients: the
parent directory is normally ////uuuussssrrrr////ssssppppoooooooollll////ppppccccnnnnffffssss and the subdirectory is the
hostname of the client system. If you wish to use a different parent
directory, you should add a line of the form
ssssppppoooooooollllddddiiiirrrr _p_a_t_h
to the ////eeeettttcccc////ppppccccnnnnffffssssdddd....ccccoooonnnnffff file.
Once a client has mounted the spool directory using NFS and has
transferred print data to a file in this directory, it will issue a
PPPPCCCCNNNNFFFFSSSSDDDD____PPPPRRRR____SSSSTTTTAAAARRRRTTTT or PPPPCCCCNNNNFFFFSSSSDDDD2222____PPPPRRRR____SSSSTTTTAAAARRRRTTTT request. ppppccccnnnnffffssssdddd handles this, and
most other print-related requests, by constructing a command based on the
printing services of the server operating system and executing the
command using the identity of the PC user. Since this involves set-user-
id privileges, ppppccccnnnnffffssssdddd must be run as root.
Every print request from the client includes the name of the printer
which is to be used. In SunOS, this name corresponds to a printer
definition in the ////eeeettttcccc////pppprrrriiiinnnnttttccccaaaapppp(5) database. If you wish to define a
non-standard way of processing print data, you should define a new
printer and arrange for the client to print to this printer. There are
two ways of setting up a new printer. The first involves the addition of
an entry to ////eeeettttcccc////pppprrrriiiinnnnttttccccaaaapppp(5) and the creation of filters to perform the
required processing. This is outside the scope of this discussion. In
addition, ppppccccnnnnffffssssdddd includes a mechanism by which you can define virtual
printers known only to ppppccccnnnnffffssssdddd clients. Each printer is defined by a line
in the ////eeeettttcccc////ppppccccnnnnffffssssdddd....ccccoooonnnnffff file of the following form
ppppccccnnnnffffssssdddd will detect when printers are added or deleted and will rebuild
its list of valid printers. To do this, it checks the modification time
of ////eeeettttcccc////pppprrrriiiinnnnttttccccaaaapppp for BSD-style systems or ////eeeettttcccc////llllpppp////pppprrrriiiinnnntttteeeerrrrssss for SVR4-based
systems. However, it does not monitor the file ////eeeettttcccc////ppppccccnnnnffffssssdddd....ccccoooonnnnffff for
updates; if you change this file, it is still necessary to kill and
restart ppppccccnnnnffffssssdddd in order that the changes can take effect.
